面试官：为什么 Spring 和 IDEA 都不推荐使用 @Autowired 注解？？

参考Spring官方文档，建议了如下的使用场景：

构造器注入： 强依赖性（即必须使用此依赖）， 不变性（各依赖不会经常变动）

Setter注入： 可选（没有此依赖也可以工作）， 可变（依赖会经常变动）

构造器注入： 强依赖性（即必须使用此依赖）， 不变性（各依赖不会经常变动）

Setter注入： 可选（没有此依赖也可以工作）， 可变（依赖会经常变动）

不能像构造器那样注入不可变的对象

依赖对外部不可见，外界可以看到构造器和setter，但无法看到私有字段，自然无法了解所需依赖

会导致 组件与IoC容器紧耦合（这是最重要的原因，离开了IoC容器去使用组件，在注入依赖时就会十分困难）

导致 单元测试也必须使用IoC容器，原因同上

依赖过多时不够明显，比如我需要10个依赖，用构造器注入就会显得庞大，这时候应该考虑一下此组件是不是 违反了单一职责原则

不能像构造器那样注入不可变的对象

依赖对外部不可见，外界可以看到构造器和setter，但无法看到私有字段，自然无法了解所需依赖

会导致 组件与IoC容器紧耦合（这是最重要的原因，离开了IoC容器去使用组件，在注入依赖时就会十分困难）

导致 单元测试也必须使用IoC容器，原因同上

依赖过多时不够明显，比如我需要10个依赖，用构造器注入就会显得庞大，这时候应该考虑一下此组件是不是 违反了单一职责原则

Field注入虽然有很多缺点，但它的好处也不可忽略：那就是 太方便了。使用构造器或者setter注入需要写更多业务无关的代码，十分麻烦，而字段注入大幅简化了它们。并且绝大多数情况下业务代码和框架就是强绑定的，完全松耦合只是一件理想上的事，牺牲了敏捷度去过度追求松耦合反而得不偿失。

那么问题来了，为什么IDEA只对@Autowired警告，却对@Resource视而不见呢？

个人认为，就像我们前面提到过的： @Autowired是 Spring提供的，它是 特定IoC提供的特定注解，这就导致了应用与框架的 强绑定，一旦换用了其他的IoC框架，是 不能够支持注入的。

而 @Resource是 JSR-250提供的，它是 Java标准，我们使用的IoC容器应当去兼容它，这样即使更换容器，也可以正常工作。

---END---

推荐↓↓↓返回搜狐，查看更多